feat: enable recursion by Oppen · Pull Request #742 · yetanotherco/lambda_vm

Oppen · 2026-06-29T21:09:42Z

Summary

Add recursion guest programs in bench_vs/lambda/: empty (no_std halt, inner program under test) and recursion (std verifier guest that deserializes a postcard-encoded (VmProof, elf, ProofOptions) and calls verify_with_options).
Makefile: compile-recursion-elfs / clean-recursion-elfs targets; test-prover-all depends on compile-recursion-elfs.
Raise MAX_PRIVATE_INPUT_SIZE from 6.7 MB → 64 MiB to fit a real VmProof as private input.
Re-export ProofOptions from the prover crate so the verifier guest can name it without a direct stark dep.
Add prover/src/tests/recursion_smoke_test.rs with ignored tests at two tiers: execute-only (in-VM verify, skips outer STARK prove) and full-prove (outer proof + host verify).
Implement deterministic randomness for non-cryptographic use, needed for HashMap access in the guest

How to test

Build the guest ELFs first:

make compile-recursion-elfs

Run the cheapest regression guard (host-only encode/decode + verify, seconds):

cargo test -p lambda-vm-prover -- --include-ignored test_recursion_blob_decodes_and_verifies_on_host

Execute-only tier (in-VM verify, no outer prove, tens of GB RAM):

cargo test -p lambda-vm-prover -- --include-ignored test_recursion_execute_1query
cargo test -p lambda-vm-prover -- --include-ignored test_recursion_execute_empty

Full pipeline (outer STARK prove + verify, ~125 GB RAM):

cargo test -p lambda-vm-prover -- --include-ignored test_recursion_prove_1query

Or via make (builds ELFs + runs all ignored prover tests):

make test-prover-all

Oppen · 2026-06-29T21:41:06Z

/ai-review
/bench

github-actions · 2026-06-29T21:43:41Z

Codex Code Review

Found 2 issues:

Medium - public APIs expose crate-private hash aliases
crypto/stark/src/lib.rs, crypto/stark/src/lookup.rs, prover/src/lib.rs, prover/src/tables/page.rs

det_hash is pub(crate), but public structs/type aliases now expose HashMap from that private module, e.g. BusPublicInputs debug fields, FinalStateMap, FinalRegisterStateMap, FiniStateMap, and epoch_boundaries params. This is likely to trigger private_interfaces under -D warnings and also makes public API types harder for downstream crates to name. Make the deterministic hash aliases public, or avoid using the private alias in public signatures.
Low - normal make test now builds ignored recursion guests
Makefile

compile-programs now depends on compile-recursion-elfs, so make test and make test-executor build the full recursion guest even though all recursion smoke tests are #[ignore] and test-prover-all already depends on compile-recursion-elfs. That adds a heavy guest build to routine test paths with no test coverage benefit. Keep recursion ELF builds scoped to test-prover-all and the explicit compile-recursion-elfs target.

Oppen · 2026-06-29T22:55:50Z

/bench
/ai-review

- Introduces smoke test with verification of empty program - Implements `get_random_custom_v03` to avoid panics when accessing hashmaps

github-actions · 2026-06-29T22:58:11Z

Codex Code Review

Findings

Medium - recursion guest terminates without HALT ecall: bench_vs/lambda/recursion/src/main.rs exports main directly and returns i32, but this guest’s config sets the ELF entrypoint to main, so it bypasses _start, which is the wrapper that calls sys_halt(). The executor may stop after returning to pc = 0, but proof trace construction requires a final ecall and returns MissingHaltEcall when building final traces. This breaks both prove_outer_and_commit and the execute-only path’s trace build. Make this guest halt explicitly after commit(&[1u8]), or enter through _start instead of main.

Notes

I reviewed only the PR diff and nearby dependencies. I did not build or run tests per the static-review constraints.

github-actions · 2026-06-29T22:59:04Z

Benchmark Results for modified programs 🚀

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
`head ecsm`	3.4 ± 0.1	3.3	3.5	1.00

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
`head hashmap`	134.4 ± 3.0	128.8	138.5	1.00

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
`head keccak`	134.0 ± 3.3	129.4	138.6	1.00

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
`head syscall_commit`	98.8 ± 3.5	95.5	107.0	1.00

claude · 2026-06-29T23:00:21Z

+# The in-VM STARK verifier. `default-features = false` drops `parallel` (no
+# threads in-guest) and `sysinfo`; the prove-side code compiles but is dead-code
+# eliminated since this guest only calls `verify_with_options`. A plain std guest
+# (build-std includes std) — no no_std plumbing needed.
+lambda-vm-prover = { path = "../../../prover", default-features = false }


The comment says default-features = false "drops ... sysinfo", but sysinfo is an unconditional dependency of the prover (prover/Cargo.toml:24), not gated behind any feature. So it is still pulled in and compiled for the RISC-V target — only parallel/rayon are actually dropped. Suggest correcting the comment to avoid implying sysinfo is excluded.

claude · 2026-06-29T23:00:22Z

+/// whole `VmProof` can be passed as private input to a verifier guest (naive
+/// recursion); the previous 6.7 MiB was too small to hold real proofs.
+pub const MAX_PRIVATE_INPUT_SIZE: u64 = 64 * 1024 * 1024;
 /// Fixed high address where private input is mapped. Guest programs can read


Raising this constant invalidates a comment elsewhere: prover/src/lib.rs:962 still says "MAX_PRIVATE_INPUT_SIZE fits in ~26 pages of DEFAULT_PAGE_SIZE". With 64 MiB and DEFAULT_PAGE_SIZE = 1 << 18 (256 KiB), max_pages is now ~257, so that comment is stale. The computed bound itself is fine (it derives from the constant), just the comment needs updating.

claude · 2026-06-29T23:00:40Z

Review: feat: enable recursion

Reviewed the non-generated changes (skipping Cargo.lock). This is mostly tooling + ignored smoke tests; the runtime-affecting changes are small and look sound. No critical or high-severity issues found.

Verified as correct (called out because they looked risky at first glance)

recursion guest returning i32 instead of halting (bench_vs/lambda/recursion/src/main.rs): unlike empty/fibonacci which end in an explicit halt() ecall, this guest returns 0 from main (the ELF entry, via -e main). That's still a clean halt: ra/x1 starts at 0, the trailing ret sets pc = 0, and the executor treats pc == 0 as termination. After commit(&[1]) this is fine.
__getrandom_v03_custom deterministic fill (syscalls/src/random.rs): seeding from the fixed-seed StdRng is intentional and actually required for a provable/deterministic VM — it just unblocks std::HashMap's RandomState. The unsafe slice construction is correctly documented and getrandom guarantees a valid non-null dest_ptr. Insecurity is documented and acceptable in this context.
MAX_PRIVATE_INPUT_SIZE 6.7 MB → 64 MiB: all consumers reference the constant directly (executor store + the verifier's num_private_input_pages bound in prover/src/lib.rs), so the change stays consistent; the page bound auto-scales (~257 pages).

Medium — build/CI coupling worth confirming is intentional

compile-programs now depends on compile-recursion-elfs, and test-executor: compile-programs. Since the recursion guest depends on the whole lambda-vm-prover (→ stark/crypto/math), make test-executor (and any compile-programs) now compiles the entire STARK verifier for the RISC-V target via build-std. That's a notable new build-time cost and a new failure surface for a previously light target. If that coupling isn't desired, consider keeping compile-recursion-elfs out of compile-programs and only wiring it into test-prover-all (which already depends on it).

Low — stale/misleading comments (inline)

prover/src/lib.rs:962 "~26 pages" comment is now stale after the 64 MiB bump (flagged inline on memory.rs).
bench_vs/lambda/recursion/Cargo.toml comment claims default-features = false drops sysinfo, but sysinfo is an unconditional prover dependency and is not dropped (inline).

Minor

recursion_smoke_test.rs asserts blob.len() < MAX_PRIVATE_INPUT_SIZE (strict) while store_private_inputs allows <=; harmless off-by-one in a test guard.

Nice touch: switching the guest .elf rules to FORCE fixes a latent bug where editing src/*.rs (only Cargo.toml was a prereq) wouldn't trigger a rebuild.

github-actions · 2026-06-29T23:01:47Z

Benchmark — ethrex 20 transfers (median of 3)

_{Table parallelism: auto (cores / 3)}

Metric	main	PR	Δ
Peak heap	72686 MB	81894 MB	+9208 MB (+12.7%) 🔴
Prove time	39.877s	42.650s	+2.773s (+7.0%) 🔴

⚠️ Regression detected — heap or time increased by more than 5%.

✅ Low variance (time: 0.6%, heap: 0.9%)

_{Commit: fcf20ef · Baseline: cached · Runner: self-hosted bench}

github-actions · 2026-06-29T23:02:47Z

AI Review

PR #742 · 16 changed files

Findings

Status	Sev	Location	Finding	Found by
candidate	high	bench_vs/lambda/recursion/src/main.rs:19	Recursion guest never halts explicitly; relies on _start's auto-halt, but main returns i32 (type mismatch with extern "C" fn main() declared as () -> ())	minimax minimax/MiniMax-M3
candidate	high	bench_vs/lambda/recursion/src/main.rs:19	Recursion guest main returns i32 and never halts — prover will error with MissingHaltEcall	moonmath zro/minimax-m3
candidate	high	bench_vs/lambda/recursion/src/main.rs:25	Recursion guest will panic on verify failure — `assert!` and `.expect` abort into undefined instruction stream	moonmath zro/minimax-m3
candidate	high	executor/src/vm/memory.rs:48	64 MiB MAX_PRIVATE_INPUT_SIZE may be insufficient for the use case, with no concrete bound check before proving the outer proof	minimax minimax/MiniMax-M3
candidate	high	syscalls/src/random.rs:43	__getrandom_v03_custom silently replaces panicking backend with a constant-seeded StdRng — wrong threat model for in-VM guests	minimax minimax/MiniMax-M3
candidate	medium	bench_vs/lambda/recursion/Cargo.lock:1	Recursion guest crate duplicates Cargo.lock (1.2k lines) with stale pins that will drift from the workspace	minimax minimax/MiniMax-M3
candidate	medium	prover/src/tests/recursion_smoke_test.rs:44	Inner prove path may reject MIN_PROOF_OPTIONS (fri_number_of_queries=1) on the host	moonmath zro/minimax-m3
candidate	medium	prover/src/tests/recursion_smoke_test.rs:221	All new recursion smoke tests are #[ignore]'d and not run in CI by default; the test_recursion_blob_decodes_and_verifies_on_host regression guard is effectively dead code in CI	minimax minimax/MiniMax-M3
candidate	medium	syscalls/src/random.rs:48	Recursion guest's `print_string` calls in __getrandom_v03_custom are no-ops in the guest build, but still print in any host build that happens to include the guest	minimax minimax/MiniMax-M3
candidate	low	Makefile:194	Inline comment in Makefile contradicts code: 'no_std inner guests' for recursion-elfs but the rule builds with -Z build-std=core,alloc,std,...	minimax minimax/MiniMax-M3
candidate	low	bench_vs/lambda/recursion/.cargo/config.toml:6	recursion guest `.cargo/config.toml` enables lower-atomic but the prover+std in-guest build still emits atomics	moonmath zro/minimax-m3
candidate	low	bench_vs/lambda/recursion/src/main.rs:15	Recursion guest uses std + no panic_handler; risky surface for in-VM verifier	moonmath zro/minimax-m3
candidate	low	executor/src/vm/memory.rs:48	MAX_PRIVATE_INPUT_SIZE 10x bump widens DoS surface for the executor	moonmath zro/minimax-m3
candidate	low	prover/src/tests/recursion_smoke_test.rs:44	Unused imports / dead code in recursion test (MIN_PROOF_OPTIONS coset/grinding may not be honored by with_blowup)	minimax minimax/MiniMax-M3
candidate	low	prover/src/tests/recursion_smoke_test.rs:109	execute_outer_and_commit discards the result of Elf::load failing case — no host-side check that the in-VM verify actually ran	minimax minimax/MiniMax-M3
candidate	low	syscalls/src/random.rs:44	Deterministic getrandom backend may subtly desync HashMap iteration order inside the in-VM verifier	moonmath zro/minimax-m3

Status column reflects the verdict from the verifier: deepseek-verifier (openrouter/deepseek/deepseek-v4-pro).

AI-001: Recursion guest never halts explicitly; relies on _start's auto-halt, but main returns i32 (type mismatch with extern "C" fn main() declared as () -> ())

Status: candidate
Severity: high
Location: bench_vs/lambda/recursion/src/main.rs:19
Found by: minimax:minimax/MiniMax-M3
Verified by: -
Rejected by: -

Claim

{'evidence': {'suggested_fix': "Either (a) declare the recursion guest's main as pub fn main() (return unit) and explicitly call lambda_vm_syscalls::syscalls::sys_halt() at the end (matching the fibonacci/empty guest style of -> !), or (b) keep the i32 return type but document the ABI mismatch and verify that LLVM/rustc treats it consistently. Option (a) is cleaner and matches the convention of the existing simple guests."}}

Evidence

Suggested fix

AI-002: Recursion guest main returns i32 and never halts — prover will error with MissingHaltEcall

Status: candidate
Severity: high
Location: bench_vs/lambda/recursion/src/main.rs:19
Found by: moonmath:zro/minimax-m3
Verified by: -
Rejected by: -

Claim

The recursion guest's main is declared pub fn main() -> i32 and never issues a halt ecall; after the final 0 return the executor keeps running whatever bytes follow in .text. The prover requires a halt ecall (see prover/src/tables/trace_builder.rs:2918-2923, which raises Error::MissingHaltEcall if none is found), so every OuterMode::Prove test in recursion_smoke_test.rs will fail to produce an outer proof — and any code reached after the return is essentially garbage execution that ends up in the trace.

Evidence

Comparing to the other recursion-suite guests that this PR adds/builds: bench_vs/lambda/empty/src/main.rs:25-28 (pub fn main() -> ! { halt() }) and bench_vs/lambda/fibonacci/src/main.rs:55-67 (pub fn main() -> ! { ...; commit(...); halt() }). The recursion guest breaks that convention. The prover's halt-finding code is cpu_ops.iter().rev().find(|op| op.decode.fields.ecall).ok_or(Error::MissingHaltEcall)?, so a guest without an ecall 93 instruction will always trip this error.

Suggested fix

Change pub fn main() -> i32 to pub fn main() -> !, drop the trailing 0, and call the halt syscall (lambda_vm_syscalls::syscalls::sys_halt() — see syscalls/src/syscalls.rs:101-112) after commit(&[1u8]), matching the pattern used by empty and fibonacci.

AI-003: Recursion guest will panic on verify failure — `assert!` and `.expect` abort into undefined instruction stream

Status: candidate
Severity: high
Location: bench_vs/lambda/recursion/src/main.rs:25
Found by: moonmath:zro/minimax-m3
Verified by: -
Rejected by: -

Claim

postcard::from_bytes(...).expect(...), verify_with_options(...).expect(...), and assert!(ok, ...) all panic on the error path, and the guest has no panic_handler (it is also not #![no_std]). With panic = "abort" from build-std, panics abort the program; combined with the missing halt syscall, this means the prover either errors out with MissingHaltEcall or generates a proof over a trace that ends in an abort/garbage stream instead of a clean halt — exactly the failure mode the smoke tests are meant to detect.

Evidence

bench_vs/lambda/empty/src/main.rs:9-12 defines its own #[panic_handler] fn panic(_info: &PanicInfo) -> ! { loop {} } for the no_std case. The recursion guest instead uses std (no #![no_std]) and panic_abort, which means a panic just aborts — but there is still no halt ecall after the abort point, so the trace continues. The other recursion-suite guests explicitly halt before returning.

Suggested fix

Either add an explicit #[panic_handler] fn panic(...) -> ! { sys_halt() } so any panic halts cleanly and the trace ends with a halt ecall, or (better, paired with the previous fix) commit(&[0u8]) + sys_halt() on the error paths instead of panicking, so the outer proof can distinguish verify-accepted vs verify-rejected.

AI-004: 64 MiB MAX_PRIVATE_INPUT_SIZE may be insufficient for the use case, with no concrete bound check before proving the outer proof

Status: candidate
Severity: high
Location: executor/src/vm/memory.rs:48
Found by: minimax:minimax/MiniMax-M3
Verified by: -
Rejected by: -

Claim

{'evidence': {'suggested_fix': 'Document the proven upper bound on serialized blob size for the chosen FRI parameters (e.g. "the roundtrip test passes up to N MiB with MIN_PROOF_OPTIONS"), or add a host-side cargo test that exercises the assertion with realistic options and rejects the change if it fails. Consider also exposing a clearer error if store_private_inputs is called with too-large input.'}}

Evidence

Suggested fix

AI-005: __getrandom_v03_custom silently replaces panicking backend with a constant-seeded StdRng — wrong threat model for in-VM guests

Status: candidate
Severity: high
Location: syscalls/src/random.rs:43
Found by: minimax:minimax/MiniMax-M3
Verified by: -
Rejected by: -

Claim

{'evidence': {'suggested_fix': 'Tighten the docstring to call out explicitly: (a) the bytes returned are public-knowledge to anyone who has read this source file (the seed is a constant in the binary), (b) never use this for security-sensitive randomness, including challenge generation or any path that touches Fiat-Shamir. If the goal is to allow HashMap to work without leaking unpredictable IDs across runs, consider documenting that explicitly. Consider also routing the getrandom v0.2 backend (which is what postcard/std often pulls) — currently the diff only adds a v0.3 backend, but the cargo dep tree at recursion/Cargo.lock shows both v0.2.16 and v0.3.4 of getrandom. Verify which one actually fires for HashMap in the recursion guest build.</value>'}}

Evidence

Suggested fix

AI-006: Recursion guest crate duplicates Cargo.lock (1.2k lines) with stale pins that will drift from the workspace

Status: candidate
Severity: medium
Location: bench_vs/lambda/recursion/Cargo.lock:1
Found by: minimax:minimax/MiniMax-M3
Verified by: -
Rejected by: -

Claim

{'evidence': {'suggested_fix': 'Either (a) use [workspace.dependencies] in the parent workspace and inherit in the recursion guest, so deps stay in lock-step, or (b) add a CI check that fails if any sub-workspace Cargo.lock pins a version that differs from the parent workspace's. The simpler fix is to add lambda_vm_suite.dependencies.serde = "1.0" to the parent and have the recursion guest reference it.'}}

Evidence

Suggested fix

AI-007: Inner prove path may reject MIN_PROOF_OPTIONS (fri_number_of_queries=1) on the host

Status: candidate
Severity: medium
Location: prover/src/tests/recursion_smoke_test.rs:44
Found by: moonmath:zro/minimax-m3
Verified by: -
Rejected by: -

Claim

The test_recursion_*_1query tests pass MIN_PROOF_OPTIONS { fri_number_of_queries: 1, grinding_factor: 1, ... } straight into crate::prove_with_options_and_inputs. Even though the test is #[ignore]d and the roundtrip test relies on the host prover succeeding, the prover can refuse arbitrary parameters — e.g. security/constraint checks that compare fri_number_of_queries against proof_options invariants — and then the test will panic on .expect("inner prove should succeed") instead of demonstrating the recursion path.

Evidence

The constant is labeled "intentionally terrible — used by the capacity-probing test", and the test asserts .expect("inner prove should succeed"). There is no prior evidence in the diff that the prover has been exercised with fri_number_of_queries=1; if it has any internal sanity check (e.g. minimum-query guards elsewhere in crypto/stark/src/prover/ or crypto/stark/src/proof/options.rs), the test would never get to the in-VM recursion part.

Suggested fix

Either (a) confirm in a comment that prove_with_options_and_inputs does not enforce a minimum query count, and that the FRI prover/verifier will both accept 1 query + grinding 1 (i.e. the test exercises what it claims to exercise), or (b) drop the _1query variants until the prover's lower bound is known and documented.

AI-008: All new recursion smoke tests are #[ignore]'d and not run in CI by default; the test_recursion_blob_decodes_and_verifies_on_host regression guard is effectively dead code in CI

Status: candidate
Severity: medium
Location: prover/src/tests/recursion_smoke_test.rs:221
Found by: minimax:minimax/MiniMax-M3
Verified by: -
Rejected by: -

Claim

{'evidence': {'suggested_fix': "Either (a) add a non-ignored variant of test_recursion_blob_decodes_and_verifies_on_host that does NOT require a prebuilt guest ELF — it could read the source of the recursion guest's main.rs and decode the layout from there, or it could just call postcard::to_allocvec with a hand-crafted dummy VmProof/inner_elf/options and decode back. This would catch layout drift on every CI run. Or (b) wire make test-prover-all (or at least the roundtrip test) into the standard CI lint/test pipeline."}}

Evidence

Suggested fix

AI-009: Recursion guest's `print_string` calls in __getrandom_v03_custom are no-ops in the guest build, but still print in any host build that happens to include the guest

Status: candidate
Severity: medium
Location: syscalls/src/random.rs:48
Found by: minimax:minimax/MiniMax-M3
Verified by: -
Rejected by: -

Claim

{'evidence': {'suggested_fix': 'Remove the print_string calls (they're no-ops anyway), or move them behind a #[cfg(target_arch = "riscv64")] with eprintln! so they're observable on the host only. If kept for parity with sys_rand, factor them into a single shared helper that documents the security implication.'}}

Evidence

Suggested fix

AI-010: Inline comment in Makefile contradicts code: 'no_std inner guests' for recursion-elfs but the rule builds with -Z build-std=core,alloc,std,...

Status: candidate
Severity: low
Location: Makefile:194
Found by: minimax:minimax/MiniMax-M3
Verified by: -
Rejected by: -

Claim

{'evidence': {'suggested_fix': 'Split into two Makefile rules: one for the no_std inner guests (empty, fibonacci) that uses -Z build-std=core,alloc,compiler_builtins,panic_abort, and one for the std recursion guest that uses -Z build-std=core,alloc,std,.... This also speeds up the no_std builds noticeably.'}}

Evidence

Suggested fix

Reviewer Lanes

Lane	Model	Prompt	Status	Findings
glm	openrouter/z-ai/glm-5.2	general	error: opencode failed (provider/auth/runtime error) and no findings were submitted	0
kimi	openrouter/moonshotai/kimi-k2.7-code	general	error: opencode failed (provider/auth/runtime error) and no findings were submitted	0
minimax	minimax/MiniMax-M3	general	success	9
moonmath	zro/minimax-m3	general	success	7
nemotron	openrouter/nvidia/nemotron-3-ultra-550b-a55b	general	error: opencode failed (provider/auth/runtime error) and no findings were submitted	0

Verification Lanes

Lane	Model	Status	Confirmed	Rejected	Uncertain
deepseek-verifier	openrouter/deepseek/deepseek-v4-pro	error: opencode failed (provider/auth/runtime error) and no verifications were submitted	0	0	0

Native Codex and Claude reviews run separately and post their own comments. They are not included in this structured provenance report.

Raw lane outputs, candidates, final issues, and model metrics are uploaded as workflow artifacts.

Oppen marked this pull request as draft June 29, 2026 21:46

Oppen force-pushed the pr/recursion-guest branch from b628a1d to 619e262 Compare June 29, 2026 22:54

yetanotherco deleted a comment from claude Bot Jun 29, 2026

yetanotherco deleted a comment from github-actions Bot Jun 29, 2026

yetanotherco deleted a comment from claude Bot Jun 29, 2026

feat: enable recursion

fcf20ef

- Introduces smoke test with verification of empty program - Implements `get_random_custom_v03` to avoid panics when accessing hashmaps

Oppen force-pushed the pr/recursion-guest branch from 619e262 to fcf20ef Compare June 29, 2026 22:56

claude Bot reviewed Jun 29, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat: enable recursion#742

feat: enable recursion#742
Oppen wants to merge 1 commit into
mainfrom
pr/recursion-guest

Oppen commented Jun 29, 2026 •

edited

Loading

Uh oh!

Oppen commented Jun 29, 2026

Uh oh!

github-actions Bot commented Jun 29, 2026

Uh oh!

Oppen commented Jun 29, 2026

Uh oh!

github-actions Bot commented Jun 29, 2026

Uh oh!

github-actions Bot commented Jun 29, 2026

Uh oh!

claude Bot Jun 29, 2026

Uh oh!

claude Bot Jun 29, 2026

Uh oh!

claude Bot commented Jun 29, 2026

Uh oh!

github-actions Bot commented Jun 29, 2026

Uh oh!

github-actions Bot commented Jun 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

Oppen commented Jun 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

How to test

Uh oh!

Oppen commented Jun 29, 2026

Uh oh!

github-actions Bot commented Jun 29, 2026

Codex Code Review

Uh oh!

Oppen commented Jun 29, 2026

Uh oh!

github-actions Bot commented Jun 29, 2026

Codex Code Review

Uh oh!

github-actions Bot commented Jun 29, 2026

Uh oh!

claude Bot Jun 29, 2026

Choose a reason for hiding this comment

Uh oh!

claude Bot Jun 29, 2026

Choose a reason for hiding this comment

Uh oh!

claude Bot commented Jun 29, 2026

Review: feat: enable recursion

Verified as correct (called out because they looked risky at first glance)

Medium — build/CI coupling worth confirming is intentional

Low — stale/misleading comments (inline)

Minor

Uh oh!

github-actions Bot commented Jun 29, 2026

Benchmark — ethrex 20 transfers (median of 3)

Uh oh!

github-actions Bot commented Jun 29, 2026

AI Review

Findings

Reviewer Lanes

Verification Lanes

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Oppen commented Jun 29, 2026 •

edited

Loading